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[0001] 



Please amend paragraph 0001 as follows: 

The present application claims priority to and is related to U.S. Provisional Patent 



Application No. 60/207,156, Confirmation No. 7007[ ], (Attorney Docket No. 36994-167671, 

formerly FE-00496) filed May, 25, 2000 entitled "Supportability Evaluation of System 
Architecture" to Johannesen et al., of common assignee to the present invention, the contents of 
which are incorporated herein by reference in their entirety. 

Please amend the following paragraphs 67-68 and add a paragraph after paragraph 0068 as 
follows: 

[0067] FIG. 6B depicts an exemplary embodiment a GUI of an exemplary implementation 
embodiment of a supportability evaluation of system architectures decision support system with a 
selected modular attribute and depicting sub-attributes of the modular attribute and nested additional 
sub-attributes of the sub-attributes according to the present invention; and 
[0068] FIG. 6C depicts an exemplary embodiment a GUI of an exemplary implementation 
embodiment of a supportability evaluation of system architectures decision support system with a 
selected reliability, maintainability and testability (RMT) attribute and depicting sub-attributes of 
the RMT attribute and nested additional sub-attributes of the sub-attributes according to the present 
invention ; and 

FIG. 6D illustrates an exemplary embodiment of the tool's capability to make pair-wise 

comparisons based on customer (subjective) priorities for a specific domain . 



[0165] FIG. 2B depicts an exemplary embodiment of a chart 218 g raphing actual life cycle costs 
incurred by a system or program 222 on a vertical access over an entire design development, 
integration and maintenance of the systems engineering process life cycle. The life cycle is shown 
running from phase 202-208. FIG. 2B also graphs commitment to system architecture and 
configuration, life-cycle cost and design to affordability (DTA), and resource requirements 220 over 
the systems engineering life cycle. 



Please amend paragraph 165 as follows: 
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Please amend paragraphs 173-175 as follows: 
[000173] FIG. 2C depicts an exemplary embodiment of a more detailed example of a systems 
engineering process 224 of FIGs. 2 A and 2B. For example, FIG. 2C could represent a more detailed 
version of phases 202 and/or 204. The detailed systems engineering process 224 begins with a 
system specification 226 and can proceed through a system level design process 228, then on to a 
subsystem level design process 230 , and then on to a software 232 and hardware 234 system design 
process, yielding a software high level design 236 and hardware high level design 238 . If used as a 
preliminary design, a similar process can be performed. 

[0001 74] FIG. 3 depicts a block diagram 300 illustrating an exemplary embodiment of a 
modular layered system architecture according to the present invention. A layered system 
architecture provides advantages of physical and functional modularity which are both useful 
supportability features. FIG. 3 includes platform architecture 302, which drives as system and sub- 
system architecture 304. FIG. 3 further illustrates how a modular layered system design 
architecture can include adoption of an application interface standards and conventions 306 -based 
solution providing further supportability features. The next layer is the application software layer 
representing the application software that runs on infrastructure 310. Infrastructure 310 is shown 
including at a base hardware level displays, system processors (SPs), databases (DBs), input output 
(I/O) subsystems, communications (Comms) subsystems, and any of various other subsystems 332. 
Above the hardware infrastructure can include any of various operating system (OS) layers 316 and 
firmware also referred to as device drivers 322 which can allow OS application functions to control, 
access and interface to hardware infrastructure 324-334. Other OS-like functions that can interface 
the infrastructural firmware can include, e.g., X/Motif 314 - a standards-based display interface, a 
Dx 318 subsystem, and a database (DB) 320 storage subsystem application. Additionally, 
application services also referred to as middleware 312 can be provided to interface from the 
application software layer 308 and the various OS-like applications 314-320. 
[000175] FIG. 4 depicts an exemplary embodiment of a hierarchy 400 of a goal and exemplary 
multiple levels of attributes and sub-attributes according to the present invention. 
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Please amend paragraphs 178-181 as follows: 
[000178] AHP consists of three phases: (a) synthesis of the relevant parameter hierarchy, (b) 
its analysis, and (c) evaluation. In designing the hierarchy, level I (i.e., top level; also called the 
Focus) of the hierarchy represents the overall objective 402 of the decision, followed by subsequent 
levels consisting of attributes 404-408 and sub-attributes 410-420 (see FIG. 4). The attributes of 
each level must be of same magnitude since they are compared with one another at the next higher 
level. For example, Reliability, Maintainability, and Supportability are subsets of Availability, 
therefore, they cannot be on the same level as Availability, but can be on the next lower level. 
Figure 4 shows the typical form of the hierarchy of AHP. The number of levels used in the 
hierarchy must be chosen to effectively represent the overall objective. In addition, each attribute 
should be limited to between 5 and 9 sub-attributes to remain effective; enough to describe the level 
in adequate detail, but without excessive complexity. The design of hierarchies can be an iterative 
process and must be done with care. 

[000179] FIG. 5 depicts an exemplary embodiment of a design 500 for supportability and 
upgradeability analytical hierarchy according to the present invention. 
[000180] Hierarchy design is unique to each individual designer. Thus, AHP requires 
experience and knowledge of the problem area. A group of people may design the hierarchy by 
reaching consensus. Figure 5 illustrates an example of a hierarchy design for a sample decision 
problem in which the objective 502 of the decision is to determine which commercial off-the-shelf 
(COTS) alternative is to be procured for a project. 

[0001 8 1] The analysis phase of AHP begins with pair- wise comparisons. The attributes , e.g. 
504-510, and sub-attributes, e.g. 512-518, in each level of the hierarchy are compared with one 
another in relative terms as to their importance/contribution to the criterion that occupies the level 
immediately above the attributes being compared. For example, a decision maker responds to a 
question that compares two attributes a and b in terms of importance or preference: "With respect 
to [overall objective], how much more important/preferred is [attribute a] than [attribute 6]." 

Please amend the first paragraph beginning on page 49, line 3 as follows: 
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When all sub-attributes have been compared pair-wise, the alternatives 422-426 must be 
compared pair-wise with respect to the sub-attributes. For example, with respect to Acquisition 
Cost, Alternative A must be compared with Alternative B, and so on. The unique feature of these 
sets of pair-wise comparisons is that the alternatives may be compared using subjective 
i udg e m e nt s i udgments (as previously done with the 1 to 9 scale) or compared using performance 
data (when available). For example, as shown in Table 5, the Acquisition Cost (dollars) or the 
Internal Compliance (number or percentage of requirements satisfied) may be available or 
estimable. In this case, it is desirable to perform the pair-wise comparisons using the performance 
data since it is objective. However, the performance data must have a linear relationship for this 
method to work, i.e., $100 is twice as good (or bad) as $50. 

Please amend paragraphs 187, 189, 191-192 as follows: 
[0001 87] FIG. 6A depicts an exemplary embodiment of a GUI 600 showing a high level 
attribute hierarchy. Figure 6A shows the four top-level attributes; Modularity, Commonality, 
Standards Based and RMT (Reliability, Maintainability and Testability) and their sub-attributes. 
Depending on the objective and scope of the evaluation, the attributes and metrics can be weighted 
subjectively. The default values are assigned by dividing the total by the number of attributes at the 
same level, for example illustrated with 0.25 across the four main attributes in FIG. 6A. 
[0001 89] FIG. 6B depicts an exemplary embodiment of a GUI 638 representing SEA - 
Modularity Sub- Attributes. 

[000191] FIG. 6C depicts an exemplary embodiment a GUI 640 of an exemplary 
implementation embodiment of a supportability evaluation of system architectures decision support 
system with a selected reliability, maintainability and testability (RMT) attribute and depicting sub- 
attributes of the RMT attribute and nested additional sub-attributes of the sub-attributes according to 
the present invention. 

[000192] FIG. 6D illustrates the tool's capability to make pair- wise comparisons based on 
customer (subjective) priorities for the specific domain in question. This was discussed in 
Appendix A. The exemplary GUI 642 illustrates the particular case where modularity is said to be 5 
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times more important than commonality. The ability to make pair-wise comparisons and assign 
priorities is applicable at all levels in the hierarchy - for attributes as well as metrics. 
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